OTN multiplexing is an alternative to synchronous optical network/synchronous digital hierarchy (SONET/SDH) multiplexing, and its simplified justification scheme provides a number of advantages when multiplexing 2.5 Gbps signals and above. OTN multiplexing does not, however, address lower-rate signals (such as Gigabit Ethernet (GbE), T1, T3, etc.), which would require multiplexing into SONET/SDH or proprietary frame formats before being handled by an OTN multiplexer. The simplified OTN frame format, multiplexing scheme, and justification methodology provide for a more straightforward and scalable hardware design than SONET/SDH methodologies.
In general, the OTN multiplexing methodology is described in the International Telecommunications Union (ITU-T) documents, including G.709 “Interfaces for the Optical Transport Network (OTN)” and G.798 “Characteristics of optical transport network hierarchy equipment functional blocks” (6/2004). G.709 defines the interfaces of the optical transport network to be used within and between subnetworks of the optical network, in terms of: optical transport hierarchy (OTH); functionality of the overhead in support of multi-wavelength optical networks; frame structures; bit rates; and formats for mapping client signals. G.798 covers the functional requirements of Optical Transport Network functionality within equipment.
OTN multiplexing includes a layered structure including Optical Payload Unit of level k (OPUk) defined within Optical Data Unit of level k (ODUk), defined within Optical Transport Unit of level k (OTUk). The OPUk is the information structure used to adapt client information for transport over an optical channel. It includes client information together with any overhead needed to perform rate adaptation between the client signal rate and the OPUk payload rate and other OPUk overhead supporting the client signal transport. This overhead is adaptation specific. OPUk capacities for k=1, k=2, k=3 are defined.
The ODUk is an information structure consisting of the information payload (OPUk) and ODUk related overhead. ODUk capacities for k=1, k=2, k=3 are defined. The path optical data unit k (ODUkP) is the information structure used to support the end-to-end ODUk trail. The optical channel transport units of level k (OTUk and OTUkV) are the information structure used for transport of an ODUk over one or more optical channel connections. The OTUk is a completely standardized optical transmission unit of level k and the OTUkV is a functionally standardized optical transmission unit of level k. Each consists of the optical data unit and OTUk related overhead (forward error correction (FEC) and overhead for management of an optical channel connection). It is characterized by its frame structure, bit rate, and bandwidth. OTUk capacities for k=1, k=2, k=3 are currently defined.
In OTN multiplexing, client streams such as OC48/STM-16 are mapped bit-for-bit, such that they can be transmitted bit-for-bit at the frequency at which they were initially received. No SONET/SDH framing is required for transmitting the transported signals. Each OC48/STM-16 is carried both 100% bit-transparently and with its original independent timing. OTN is transparent to the payload it transports within the ODUk and that the OTN layer does not need to transport network synchronization since network synchronization can be transported within the payload, i.e. by SONET/SDH client tributaries.
For carriers wishing to provide wavelength services, OTN multiplexing provides a simpler, more straightforward, and ultimately more cost-effective, transport mechanism than SONET/SDH. However, OTN multiplexing is limited by the ITU-T specifically excluding network synchronization between network elements (NEs) from OTN specifications.
Testing and analysis has confirmed that jitter and wander noise accumulate to levels above that which network operators are comfortable with. For example, the jitter generation specification limits jitter to 100 mUI pkpk and 10 mUI rms. Network operators prefer numbers below 90 mUI pkpk and 9 mUI rms. These tests are supposed to be performed with a jitter-free source, but customers typically test over one or more spans. After several non-synchronized, concatenated OTN multiplexers, the jitter generated is over the 90 mUI pkpk and 9 mUI rms levels. When the same testing is performed over synchronized, concatenated spans, the jitter generation drops below 50 mUI pkpk and 5 mUI rms. Other, non-SONET/SDH signals, such as video transport, require even tighter jitter and wander limits.
Without synchronization, extreme filtering of the transmitted signal could reduce the noise to more acceptable limits. However, such measures would involve extensive testing, and efficacy would vary from run to run, product to product, and vendor to vendor. The filtering would involve proprietary solutions, not well understood and not verified under real world experience.
Of note, 100% bit-transparent multiplexing of SONET/SDH signals has been in demand for many years. Several proprietary approaches have been developed, with varied success. OTN multiplexing is a solution to this problem, and is a standards-based approach that will be in high demand. Once addressed, the lack of external synchronization will become an issue. Having a synchronization-optional approach will thus be an advantage.